In distributed embedded control environments I/O engines are often remotely attached to the embedded controller through a serial link. Typically access to these devices is facilitated by directly programming the serial link controller hardware.
FIG. 1 shows such an environment where an embedded controller needs to operate a series of I/O devices which are attached at the remote end of a link.
At the lowest level a microprocessor accesses I/O resources either through its I/O address space for architectures such as the Intel x86, or through its memory address space for architectures such as the IBM PowerPC architecture. The software entity that controls the hardware at this level is usually called a Device Driver. Towards higher level software applications the Device Driver provides a generic view of the device. In UNIX systems, it is typically visible in the hierarchical file-system name space in the /dev tree and access to it is facilitated using regular file-system semantics and interfaces like:                open( );        close( );        read( );        write( );        ioctl( )        
In embedded control applications it is not always possible to attach all I/O devices such that they can be directly addressed at the microprocessor bus level as shown in FIG. 2. The I/O functions are often implemented in a standalone ASIC which can be attached to the embedded controller's microprocessor via some link hardware. Consequently, the resources of the I/O devices are not directly visible in the I/O address space or memory address space of the microprocessor. What is visible to the microprocessor though are the resources of the link hardware that connects the I/O ASIC with the embedded controller.
Since no existing device driver can be used in this situation the full software path to the I/O devices needs to be facilitated through custom device interface software. The need for this custom device interface software is a limiting factor for time-to-market which is often key in the embedded control market nowadays.
In addition custom implementation of the device driver layer increases the probability of shipping software bugs to the field which cannot be easily recovered from. Unlike regular PC applications where it is relatively simple to download a new version of a previously buggy application over the Internet, it is not easily possible to replace faulty software in embedded control applications.
Until recently this problem did not exist because embedded control applications traditionally used custom operating systems, custom device drivers, and custom hardware. Since the problem is rather new, standard solutions are not yet available, however, with the emerging push towards standardization in embedded control environments new solutions will become more prevalent.
A major driver towards this standardization is Linux and the overall OpenSource movement.